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1.0  Scope 


1.1  Identification. 

The  Refractivity  from  Clutter  (RFC)  Version  1.0  computer  software  configuration  item 
(CSCI)  uses  techniques  for  inferring  atmospheric  refractive  conditions  from  radar 
backscatter.  It  applies  to  evaporation  ducts  (EDs),  surface-based  ducts  (SBDs),  and 
whether  the  observed  backscatter  is  from  the  sea,  land,  or  known  point  targets. 

1 .2  System  Overview. 

The  RFC  system  will  infer  atmospheric  refractivity  from  radar  sea  clutter.  The  system 
will  use  information  obtained  by  going  “Through-the-Sensor  Means”  to  provide  refrac¬ 
tive  effects  that  can  characterize  the  electromagnetic  environment.  This  characterization 
can  enhance  the  radar  and  weapons  performance  assessment  to  maximize  the  warfighter’s 
battlespace.  The  RFC  system  will  be  realized  as  a  bootable  PowerPC®  Verification,  Exe¬ 
cution  and  Rewrite  System  (VERSA)  Module  Eurocard  (VME)  computer-on-a-board. 

The  system  will  poll  universal  format  (UF)  data  files  containing  the  clutter  measurements 
needed  for  RFC  from  the  Tactical  Environmental  Processor  (TEP)  provided  by  Lockheed 
Martin®. 

1.3  Document  Overview. 

The  RFC  System  must  meet  the  software  functional  requirements  specified  in  this 
document.  The  input  software  requirements  are  discussed  and  the  internal  structure  of  the 
RFC  CSCI  is  described  as  it  relates  to  CSCI’s  capability. 

2.0  Reference  Documents. 

(a)  L.  T.  Rogers,  C.  P.  Hattan,  and  J.  K.  Stapleton.  2000.  “Estimating  Evaporation 
Duct  Heights  from  Radar  Sea  Clutter,”  Radio  Science,  vol.  35,  no.  4  (July- 
August),  pp. 955-966. 

(b)  P.  Gerstoft,  L.  T.  Rogers,  J.  Krolik,  and  W.  S.  Hodgkiss.  2002.  “Inversion  for 
Refractivity  Parameters  from  Radar  Sea  Clutter,”  Radio  Science,  vol.  38,  no.  3. 

(c)  S.  Vasuvedan,  R.  H.  Anderson,  J.  L.  Krolik,  L.  T.  Rogers,  and  P.  Gerstoft. 
“Recursive  Bayesian  Electromagnetic  Refractivity  Estimation  from  Radar  Sea 
Clutter,”  IEEE  Transactions  On  Signal  Processing,  submitted  for  publication. 

(d)  P.  Gerstoft,  L.T.  Rogers,  W.  S.  Hodgkiss,  and  L.  J.  Wagner.  2003.  “Refractivity 
Estimation  Using  Multiple  Elevation  Angles,”  IEEE  Oceanic  Engineering, 
vol.  28  (July). 

3.0  Requirements 

3.1  Required  States  and  Modes. 

No  states  or  modes  are  required. 
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3.2  CSCI  Capability  Requirements. 

The  required  RFC  CSCI  algorithms  use  radar  backscatter  from  Lockheed  Martin’s  TEP 
system  to  determine  refractivity  profiles  of  the  environment.  Figure  1  shows  the  program 
flow  of  the  required  RFC  CSCI.  Figures  2  through  6  show  the  program  flow  for  the  main 
computer  software  components  (CSCs),  RFC  Reader  CSC,  RFC  Data  Quality  CSC,  RFC 
Classifier  CSC,  RFC  ED  CSC,  and  RFC  SBD  CSC,  respectively. 


Figure  1.  RFC  CSCI  program  flow. 
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Figure  2.  RFC  Reader  CSC  program  flow. 
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Figure  3.  RFC  Data  Quality  CSC  program  flow. 


4 


•  Enter  from  , 
I  RFC  Driver 


Operate  on  radar 
azimuths  with 
fixed  sectors 


Figure  4.  RFC  Classifier  CSC  program  flow. 
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Figure  6.  RFC  SBD  CSC  program  flow. 


3.2.1  Refractivitv  from  Clutter  Initialization  CSC. 


The  RFC  Initialization  CSC  initializes  registers,  flags,  and  checks  to  see  if  a  new  UF  file 
exists  on  the  TEP  system.  During  this  time,  the  stored  replica  fields  of  evaporation  and 
SBD  refractive  profiles  are  also  loaded  into  memory. 

3.2. 1.1  RFC  Read  Evaporation  Profiles  SU. 


The  Read  Evaporation  Profiles  SU  (software  unit)  reads  the  binary  file  EvapProfiles  into 
memory.  This  file  contains  a  precompiled  set  of  evaporation  duct  replica  fields  that  will 
be  used  in  the  RFC  ED  CSC. 


3.2. 1.2  RFC  Read  SBD  Profiles  SU. 


The  Read  SBD  Profiles  SU  reads  the  binary  file  SBDProfiles  into  memory.  This  file 
contains  a  precompiled  set  of  SBD  replica  fields  that  will  be  used  in  the  RFC  SBD  CSC. 
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3.2. 1.3  RFC  Read  Random  Numbers  SU. 


The  Read  Random  Numbers  SU  reads  the  binary  file  RandomNumbers  into  memory. 

This  file  contains  a  set  of  random  numbers  that  will  be  used  in  the  Generate  Markov  Shift 
SU. 


3.2. 1.4  RFC  Generate  Markov  Shifts  SU. 

The  RFC  Generate  Markov  Shifts  SU  shifts  in  range  and  amplitude  each  SBD  replica 
field.  These  newly  generated  replica  fields  are  then  used  in  the  RFC  SBD  CSC. 

3.2.2  Refractivitv  from  Clutter  Reader  CSC. 

The  RFC  Reader  CSC  reads  a  binary  universal  format  (UF)  file  from  the  TEP  weather 
data  processor  (WDP).  The  spectral  moments  for  each  dwell  are  stored  for  processing.  It 
also  checks  to  see  if  the  file  is  fragmented  (non-usable);  if  so,  it  then  sends  control  back 
to  the  RFC  Initialization  CSC.  If  usable,  the  data  are  sent  to  the  RFC  Data  Quality  CSC. 

3.2.1 .1  RFC  Read  UF  SIJ. 

The  Read  UF  SU  reads  the  binary  UF  file  from  the  TEP  system  and  formats  it  into  an 
observed  data  structure.  It  also  checks  to  see  if  the  file  is  not  fragmented.  If  fragmented, 
control  is  sent  back  to  the  RFC  Initialization  CSC. 

3-2.3  Refractivitv  from  Clutter  Data  Quality  CSC. 

The  RFC  Data  Quality  CSC  determines  what  limits  and  what  parts  of  the  data  will  be 
used  in  the  RFC  ED  and  RFC  SBD  algorithms.  The  data  are  then  stored  in  memory  for 
other  algorithms  to  retrieve. 

3.2.3.1  RFC  FindLand  SIJ. 

The  RFC  FindLand  SU  uses  Digital  Terrain  and  Elevation  Data  (DTED)  stored  on  a  hard 
drive  to  find  the  range  at  which  land  begins.  It  stores  that  range  in  memory. 

3.2. 3.2  RFC  FindSectorLumns  SIJ. 

The  RFC  Find  Sector  Lumps  SU  finds  and  stores  all  protrusions  that  could  possibly  be 
weather,  surface-based  ducting,  or  point  targets.  It  also  finds  the  range  limit  at  which  the 
RFC  ED  algorithm  will  compare  the  slope  of  the  observed  clutter  power  to  the  slope  of 
the  modeled  clutter  power  from  the  replica  fields. 

3.2.3.3  RFC  FindPtTargets  SU. 

The  RFC  Find  Point  Targets  SU  tests  all  the  protrusions  that  the  FindLumps  SU  flagged 
to  see  if  they  meet  the  criteria  for  a  possible  point  target.  Point  targets  are  those  radar 
returns  that  come  from  other  ships  at  sea.  If  the  protrusion  is  a  point  target,  it  is  removed 
from  the  interpolated  data.  These  data  are  then  stored  in  memory. 
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3.2.3.4  RFC  Interpolator  SU. 

The  RFC  Interpolator  SU  interpolates  the  spectral  moment  to  1 -kilometer-range  bins.  The 
interpolated  spectral  moments  are  reflectivity,  signal-noise  ratio  (SNR),  and  radial 
velocity. 

3.2.4  Refractivitv  from  Clutter  Data  Classifier  CSC. 

The  RFC  Classifier  CSC  determines  whether  the  interpolated  spectral  moments  have 
individual  sectors  of  surface-based  ducting,  evaporation  ducting,  or  non-ducting,  such  as 
weather,  in  them.  If  surface-based  ducting  is  detected,  and  this  information  is  sent  to  the 
RFC-SBD  SU.  If  evaporation  ducting  is  detected,  this  information  is  sent  to  the  RFC  ED 
SU.  If  weather  is  detected,  this  sector  is  then  flagged  as  non-usable  in  the  RFC  SBD  and 
RFC  ED  SUs.  A  standard  atmospheric  reffactivity  profile  is  output  for  that  particular 
sector. 


3.2.4. 1  RFC  Data  Classifier  SU. 

The  RFC  Data  Classifier  SU  distinguishes  between  weather-related  and  surface-based 
ducting  data.  Data  determined  to  be  weather-related  is  no  longer  used  in  the  RFC 
algorithms.  Only  surface-based  ducting  data  are  passed  to  the  RFC  SBD  SU.  Data 
uncorrupted  by  weather  during  the  first  20  kilometers  are  then  passed  to  the  RFC  ED  SU. 

3.2.5  Refractivitv  from  Clutter  ED  CSC. 

The  RFC  ED  CSC  finds  the  evaporation  duct  height  by  comparing  the  slope  of  the 
interpolated  clutter  power  to  the  slope  of  the  modeled  clutter  power  obtained  from  the 
refractivity  replica  fields  that  are  precompiled  and  stored  in  memory.  The  best  fitting  ED 
replica  refractivity  profile  is  then  output  to  an  RFC  Output  File  format,  which  is  defined 
in  the  RFC-Shipboard  Environmental  Assessment  WeApon  System  Performance 
(SEAWASP)  Interface  Design  Specification  document.  This  file  is  then  written  to  the 
TEP  recorder  and  passed  to  SEAWASP  via  Ethernet. 

3.2.5. 1  RFC  Find  Mavg  SU. 

The  RFC  Find  Mavg  SU  determines  the  range  cutoff  for  each  individual  dwell  within 
each  sector  used  in  the  RFC  InvertEvap  SU.  This  range  limitation  could  result  from 
hitting  the  noise  floor,  point  target,  or  weather. 


3.2.5.2  RFC  Invert  Evaporation  SU. 

The  RFC  Invert  Evaporation  SU  compares  the  SNR  spectral  moment  to  the  precompiled 
evaporation  replica  fields  that  were  loaded  during  the  RFC  Initialization  CSC.  A  least- 
squares  estimation  compared  an  integration  length  of  no  less  than  4  kilometers. 

3.2.6  Refractivitv  from  Clutter  SBD  CSC. 

The  RFC  SBD  CSC  finds  the  set  of  refractivity  replica  fields  that  best  match  the  fit  of  the 
interpolated  clutter  data  to  the  modeled  clutter  data.  The  results  are  found  for  those 
individual  sectors  that  were  classified  as  SBD  by  the  RFC  Data  Classifier  CSC.  The 
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best  fit  SBD  refractive  profile  is  then  output  to  an  RFC  Output  File,  which  is  defined  in 
the  RFC-SEAWASP  Interface  Design  Specification  document.  This  file  is  then  written  to 
the  TEP  recorder  and  passed  to  SEAWASP  via  Ethernet. 

3.2.6. 1  RFC  Calculate  Square  Error  SI  J. 

The  RFC  Calculate  Square  Error  SU  calculates  the  squared  error  between  the  median 
filtered  reflectivity  spectral  moment  and  the  markov  range  and  amplitude-shifted, 
precompiled  SBD  replica  fields.  This  information  is  then  passed  to  the  RFC  Get  Map 
Estimate  SU. 


3.2.6.2  RFC  Get  Map  Estimate  SU. 

The  RFC  Get  Map  Estimate  SU  chooses  the  “best  matching”  field  out  of  the  set  of 
precompiled  SBD  replica  fields. 


3.2.7  RFC  Output  File. 

The  output  file  from  the  RFC  algorithms  shall  consist  of  the  following:  (1)  if  an  ED  is 
detected,  a  neutral  (ED)  refractivity  profile  will  be  output;.  (2)  if  a  SBD  is  detected,  the 
best  matching  range-dependent  SBD  refractive  profile  for  up  to  three  sectors  will  be 
output,  (3)  if  no  ED  or  SBD  is  detected  in  any  of  the  sectors,  then  a  standard  atmospheric 
refractivity  profile  will  be  output  along  with  a  flag  as  to  the  reason  behind  defaulting  to  a 
standard  atmosphere,  (4)  the  start  bearing  and  stop  bearing  of  each  individual  sector; 

(5)  the  confidence  level  (i.e.,  High,  Medium,  and  Low)  of  each  classified  sector. 

The  format  of  the  RFC  Output  File  is  documented  in  the  Attachment  to  John  Hopkins 
University  (JHU)/Applied  Physics  Laboratory  (APL)  Technical  Memo  A2A-04-U-3-009, 
which  is  in  the  Appendix. 

3.3  CSCI  External  Interface  Requirements. 

The  RFC  CSCI  external  data  elements  consist  of  the  RFC  Data  Input  UF  file  generated 
by  the  Lockheed  Martin®  TEP  system. 

3.3.1  Interface  Identification  and  Diagrams. 

The  RFC  Initialization  CSC  polls  the  TEP  system  (reference  Figure  1)  to  see  if  a  new  UF 
file  was  generated.  Within  this  data  file  is  information  necessary  for  the  RFC  algorithms 
to  process  and  calculate  environmental  refractivity  profiles  necessary  for  radar  perform¬ 
ance  and  assessment  to  the  warfighter.  The  results  from  the  RFC  CSCI  are  then  output  to 
a  file  for  retrieval  by  SEAWASP  over  the  ship  Ethernet  and  also  output  to  the  TEP 
recorder  for  storage.  Table  1  lists  the  data  elements  required  from  the  UF  file  for  the  RFC 
CSCI. 


10 


Table  1.  RFC  CSCI  external  data  element  requirements. 


Name 

Description 

Type 

Units 

Bounds 

Date/Time 

UTC 

Integer 

N/A 

None 

Latitude 

Ship  Position 

Float 

Degrees 

None 

Longitude 

Ship  Position 

Float 

Degrees 

None 

DBZ 

Reflectivity 

Float 

Decibels 

None 

SNR 

Signal-Noise 

Ratio 

Float 

Decibels 

None 

SW 

Spectrum  Width 

Float 

meters/sec 

None 

VR 

Radial  Velocity 

Float 

meters/sec 

None 

MTI1 

1st  Pulse  MTI 

Float 

decibels 

None 

MTI_2 

2na  Pulse  MTI 

Float 

decibels 

None 

MTI_3 

3ra  Pulse  MTI 

Float 

decibels 

None 

Az 

Azimuth 

Float 

degrees 

0  to  360 

El 

Elevation 

Float 

degrees 

0  to90 

Range 

Range  Bins 

Float 

meters 

None 

Range 

Transition 

RFA  Range 
Switch  Out 

Float 

meters 

None 

Transmit  Power 

Power  Level 

Integer 

None 

High/Low 

WvType 

Waveform 

Integer 

None 

None 

SPY-1  Doctrine 

NA 

NA 

NA 

NA 

3.4  CSCI  Internal  Interface  Requirements. 

Section  3.2  shows  the  relationship  between  the  RPC  CSCI  and  its  five  CSCs:  RFC 
Reader,  RFC  Data  Quality,  RFC  Classifier,  RFC  ED,  and  RFC  SBD.  The  required 
internal  interface  between  these  five  CSCs  and  the  RFC  CSCI  is  left  to  the  designer. 
However,  Table  2  should  be  used  as  a  guide  to  the  required  internal  interfaces  in  the 
CSCI. 

3.5  CSCI  Internal  Data  Requirements. 

The  internal  data  requirements  are  left  to  the  designer. 

3.6  Adaptation  Requirements. 

The  TEP  UF  file  will  have  parameters  that  indicate  the  waveform  type  transmitted  by  the 
radar,  whether  the  radio  frequency  attenuation  (RFA)  was  used  during  transmission,  and 
when  an  RFC-dedicated  dwell  was  transmitted. 
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3.7  Safety  Requirements. 
None. 


3-8  Security  and  Privacy  Requirements. 

None. 

3.9  CSCI  Environment  Requirements. 

The  RFC  CSCI  will  operate  on  a  bootable  PowerPC*  VME  computer-on-a  board  in  the 
TEP  cabinet.  The  operating  system  is  Linux  and  the  application  will  be  written  in 
C  language  using  Vector  Signal  Image  Processing  Library  (VSIPL)  functions.  To  use 
VSIPL  functions  on  a  given  platform,  a  VSIPL-compliant  library  will  be  available  for 
particular  hardware.  A  tool-set  (linker)  will  also  be  available  for  the  operating  system. 

3.10  Computer  Resource  Requirements. 

3.10.1  Computer  Hardware  Requirements. 

The  RFC  CSCI  will  reside  on  a  bootable  PowerPC®  VME  board.  The  DTED  database 
and  refractivity  replica  fields  for  ED  and  SBD  will  reside  on  a  hard  drive  in  the  TEP 
processor  cabinet. 


3.10.2  Computer  Hardware  Resource  Utilization  Requirements. 

Table  2  lists  the  storage  requirements  for  the  databases  used  in  the  RFC  CSCI. 


Table  2.  Database  storage  requirements. 


Database 

Storage 

%  Auxiliary  Storage 

ED  replica  fields 

25  KB 

0 

SBD  replica  fields 

75  MB 

0 

Random  numbers 

300  Kb 

0 

DTED 

5  GB 

0 

3.10.3  Computer  Software  Requirements. 

The  software  requirements  consist  of  using  a  middleware  that  is  open  architecture  (OA)- 
compliant.  This  middleware  allows  RFC  application  portability  between  hardware 
systems  without  major  code  changes.  VSIPL  is  the  OA-compliant  middleware  used  for 
the  RFC  application. 
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3.10.4  Computer  Interface  Requirements. 

Lockheed  Martin®  will  incorporate  the  interface  requirements  between  RFC-TEP  in  TEP 
system  documentation.  The  Interface  Design  Specification  document  will  incorporate  the 
interface  requirements  between  RFC-SEAWASP. 

3.1 1  Software  Quality  factors. 

The  primary  required  quality  factors  can  be  divided  into  the  three  categories:  design, 
performance,  and  adaptation. 

3.11.1  Design. 

The  quality  factors  for  the  design  category  should  include  correctness,  maintainability, 
and  verifiability.  Correctness  describes  the  extent  to  which  the  RFC  CSCI  conforms  to  its 
requirements  and  is  determined  from  the  following  criteria:  completeness,  consistency, 
and/or  traceability.  Maintainability  specifies  the  effort  required  to  locate  and  fix  an  error 
in  the  RFC  CSCI.  Maintainability  is  determined  from  the  following  criteria:  consistency, 
modularity,  and  self-documentation.  Verifiability  characterizes  the  effort  required  to  test 
the  RFC  CSCI  to  ensure  that  it  performs  its  intended  function.  Verifiability  is  determined 
from  the  following  criteria:  modularity  and  self-documentation. 

3.1 1.2  Performance. 

The  quality  factor  for  the  performance  category  is  reliability,  which  shows  the  confidence 
that  can  be  placed  in  the  RFC  CSCI  calculations.  Reliability  is  determined  from  the 
following  criteria:  accuracy  and  consistency. 

The  Naval  Surface  Warfare  Center  (NSWC)  Dahlgren  Division  uses  Wallops  Mission 
2000  experimental  data  (Table  3)  determines  the  accuracy  and  consistency  criteria  for  the 
RFC  SBD  SU.  Experimental  data  collected  using  the  TEP  system  when  it  was 
demonstrated  on  USS  O’ Kane  and  USS  Normandy  (Figure  7)  determines  the  accuracy 
and  consistency  criteria  for  the  RFC  ED  SU. 

3.1 1.3  Adaptation. 

None. 

3.12  Design  and  Implementation  Constraints. 

VSIPL  functions  and  libraries  are  used  as  an  open  architecture  for  the  software. 

3.13  Personnel-Related  Requirements. 

None. 

3.14  Training-Related  Requirements. 

None. 
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3.15  Logistics-Related  Requirements. 

SSC  San  Diego  Code  2858  will  handle  all  logistics. 


3.16  Other  Requirements. 

None. 

3.17  Packaging  Requirements. 

None. 

3.18  Precedence  and  Criticality  of  Requirements. 

None. 

4.0  Qualification  Provisions. 

None. 

5.0  Requirements  Traceability. 

None. 

6.0  Notes. 

6.1  Glossary. 

CSC-Computer  Software  Component 
CSCI-Computer  Software  Configuration  Item 
DTED-Digital  Terrain  Elevation  Data 
ED-Evaporation  Duct 

JHU/APL- Johns  Hopkins  University/Applied  Physics  Laboratory 

OA-Open  Architecture 

RFC-Refractivity  from  Clutter 

SBD-Surface-Based  Duct 

SU-Software  Unit 

TEP-Tactical  Environmental  Processor 
UF-Universal  Format 
VME-VERSA  Module  Eurocard 
VSIPL-Vector,  Signal,  and  Image  Processing  Library 
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Table  3.  Test  results  from  IV&V  testing  by  NSWC  Dahlgren  Division. 


Confidence 

Level 

Band 

RFC 

Rocketsonde 

Range- 

Dependent 

Helicopter 

Single 

Profile 

Helicopter 

Free 

Space 

Standard 

Atmosphere 

50% 

S 

4.0 

5.1 

3.4 

3.7 

4.8 

15.7 

C 

4.8 

3.9 

3.5 

3.5 

4.8 

17.7 

X 

5.3 

4.9 

3.7 

3.7 

3.7 

10.9 

90% 

S 

14.3 

16.6 

10.2 

12.2 

13.1 

51.2 

C 

15.9 

18.3 

12.0 

12.3 

13.3 

55.4 

X 

15.4 

13.9 

11.7 

12.3 

10.5 

51.1 

Figure  7.  Test  results  from  USS  Normandy. 


7.0  Appendix 

Attachment  to  JHU/APL  Technical  Memo  A2A-04-U-3-009 

PURPOSE 


This  Interface  Design  Specification  (IDS)  defines  the  digital  interface  between  the 
Reffactivity  From  Clutter  (RFC)  Module  in  the  Tactical  Environmental  Processor  (TEP) 
Open  Architecture  (OA)  system,  and  the  Shipboard  Environmental  Assessment  WeApon 
System  Performance  (SEAWASP)  system.  The  IDS  has  been  specifically  designed  to 
parallel  the  interface  between  the  data  server  process  of  the  Shipboard  Meteorological 
and  Oceanographic  Observation  System  (SMOOS)  and  SMOOS  clients,  in  order  to 
facilitate  interface  development  and  to  facilitate  the  use  of  SMOOS/SEAWASP  to 
validate  RFC  algorithms. 

Network  Interface  Protocol 

This  section  describes  the  network  interface  protocol  used  to  manage  the  flow  and 
processing  of  information  between  the  TEP  RFC  module  and  SEAWASP. 
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The  interface  has  two  sides:  a  data  server  residing  in  the  RFC  Module  and  a  data  client 
residing  in  the  SEAWASP  processor. 

General  Protocol  Features 

The  server  communicates  with  the  client  using  the  TCP/IP  protocol  via  port  9050  using 
connected  sockets.  If  the  client  is  external  to  the  TEP  processors’  cabinet,  the  client  and 
server  processes  will  require  an  Ethernet  LAN  connection. 

Connection  Establishment  and  Validation 

The  client  connects  to  the  server  through  a  TCP  stream  socket.  Once  the  client  establishes 
connection  with  the  server,  it  has  10  seconds  to  identify  itself  by  sending  Message  Type 
(MT)  2000.  If  identification  is  valid  and  the  client  has  enabled  at  least  one  interface 
message,  the  server  replies  with  MT  1000  to  indicate  that  the  connection  has  been 
accepted  and  the  server  is  ready  for  data  transactions  with  the  client.  If  identification  fails 
or  the  client  does  not  enable  any  messages  within  the  allowable  time  frame,  the  server 
replies  with  MT  1001  (connection  rejected),  closes  the  socket,  terminates  the  connection, 
and  remains  in  listening  mode  waiting  for  a  new  connection. 


Client 

. - JV 

Server 

2000  > 

(accept) 

(reject) 


Figure-1 .  Establishment  of  Connection. 


Message  Exchange 

Once  a  valid  connection  has  been  established,  the  server  will  periodically  send  the  client 
all  enabled  interface  messages. 

The  client  can  enable  or  disable  interface  messages  by  sending  a  new  message  of  MT 
2001  to  the  server.  The  server  enables  a  certain  message  when  the  corresponding  bit  in 
MT  2001  is  set  to  1,  and  continues  sending  it  until  the  connection  is  disabled  or  the  client 
asks  to  stop  receiving  the  message.  The  client  requests  the  server  to  stop  sending 
messages  of  a  specific  type  by  setting  the  appropriate  bit  to  0  in  MT  2001 . 


16 


Message  Format 

All  data  messages  for  communications  between  the  server  and  the  client  consist  of  five 
distinct  data  fields:  Message  Length,  Message  Type,  Message  Data,  Message  Time,  and 
Message  Terminator. 


Table-1.  Message  Format. 


MSG  LENGTH 

MSG  TYPE 

MSG  DATA 

MSG  TIME 

MSG 

TERMINATOR 

4  bytes,  uint 

2  bytes,  ushort 

Variable 

4  bytes,  uint 

2  bytes,  “##’ 

•  MSG  LENGTH  -  This  binary  field  is  four  bytes  long  and  indicates  message  length  in  bytes. 
This  field  includes  only  the  length  of  the  data  contained  in  MSG  DATA  field. 

•  MSG  TYPE  -  This  binary  field  is  two  bytes  long  and  identifies  type  of  message.  Server-to- 
client  message  types  start  at  1000  while  client— to— server  message  types  start  at  2000. 

•  MSG  DATA  -  This  variable  field  contains  the  actual  data  specific  to  each  message  type.  The 
data  in  this  field  can  be  either  binary  or  ASCII  depending  on  message  type.  All  data  is  in 
Network  Byte  Order  (NBO)  unless  noted  otherwise. 

•  MSG  TIME  -  (This  field  is  included  for  compatibility  with  a  “SMOOS-like”  system,  and  can 
be  set  to  zero,  as  the  data  time  of  interest  to  SEAWASP  will  be  contained  in  the  MSG  DATA 
field.)  This  binary  field  is  four  bytes  long  and  indicates  the  server’s  or  client’s  system  real¬ 
time-clock,  in  milliseconds,  at  the  time  the  message  was  written  to  the  socket.  The  time  is 
reset  to  zero  when  the  METOC  Processor  and  this  server  is  restarted.  Since  this  time  is  stored 
as  a  four  byte  data  field,  to  avoid  overflow,  it  will  wrap  around  to  zero  if  the  system  is  run 
continuously  for  49.7  days 

•  MSG  TERMINATOR  -  This  ASCII  field  is  two  bytes  long  and  indicates  end  of  message. 

The  two  bytes  in  this  field  are  Sharp  characters  (*##’). 

Network  Byte  Order 

Data  fields  that  have  a  data  type  of  ushort,  int,  uint,  float,  double  or  double  uint  are 
converted  into  network  byte  order  prior  to  sending  the  message  to  the  client. 

ushort  -  two-byte  unsigned  value 

int  -  four-byte  integer  value 

uint  -  four-byte  unsigned  integer  value 

float  -  four-byte  floating-point  value 

double  -  eight-byte  floating-point  value 

double  uint  -  eight-byte  unsigned  integer  value 

byte  -  unsigned  eight-bit  value 

char  -  ASCII  NULL  terminated  string 


Message  Data  Description 

The  following  sections  define  the  MSG  DATA  field  format  for  each  message  type.  The 
common  definitions  of  the  fields  comprising  each  message  type  are  given  in  Table  2. 
Message-specific  definitions  are  provided  following  the  message’s  field  definition  table. 
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Table-2.  Data  Field  Definitions. 


Field  Type 

Range  and  Units1 

Format/Description 

Alt  MSL 

0  to  65,000  feet 

Altitude  as  nnnnn  which  is  the  measured  or 
calculated  height  above  mean  sea-level 

Confidence 

Table  3 

Confidence  codes. 

Range 

0  to  ???  NMI 

Profile  Range  to  xxx.x  nmi 

Duct  Height 

0  to  ???  feet 

Evaporation  Duct  Height  as  nnn.n  above  sea  level 

Latitude 

-90  to  +90  degrees 

Latitude  as  ±nn.nnnn  where  +  indicates  North  and  - 
indicates  South 

Longitude 

-180  to  +180  degrees 

Longitude  as  ±nnn.nnnn  where  +  indicates  East  and 
-  indicates  West 

Refractivity 

M-units 

Modified  Refractivity  as  nnn.nn 

UTC 

Table  4 

UTC  (Z)  date  and  time  as  DateTime  Data  Type 
using  WindowsNT  “Monrovia,  Casablanca”  time 
zone  setting 

Table-3.  Confidence  Field  Codes. 


Value 

Description 

0 

Low 

1 

Medium 

2 

High 

255 

Unknown  or  no  Data  Available 

Table-4.  UTC  Field  Type  Subfields. 


SubField  Name 

Description2 

Beg:Len 

Data  Type 

a.  Year 

4-digit  year  (Y2K  compliant) 

0:4 

int 

b.  Month 

month  of  year  (1  to  12) 

4:4 

int 

c.  Day 

day  of  month  (1  to  31) 

8:4 

int 

d.  Hour 

hour  of  day  (24-hour  clock) 

12:4 

int 

e.  Minutes 

minutes  of  hour  (0  to  59) 

16:4 

int 

f.  Seconds 

seconds  of  minute  (0  to  59) 

20:4 

int 

g.  Milliseconds 

milliseconds  of  second 

24:4 

int 

1  The  absence  of  a  valid  float  data  type  value  is  indicated  by  a  value  equal  to  -9999.0.  The  absence  of  a 
valid  int  data  type  value  is  indicated  by  a  value  equal  to  -9999. 

The  absence  of  a  valid  UTC  is  indicated  by  all  subfield  values  equal  to  0. 
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Server-to-Client  Messages 

The  server  may  send  the  following  messages  to  the  client: 

•  Client  Connection  Accepted  (Type  1000)  -  page  19 

•  Client  Connection  Refused  (Type  1001)  page  19 

•  Bearing-Range-Altitude-Refractivity  Profile  Data  (Type  1023)  -  page  20 

•  Error  (Type  1 0 1 4)  -  page  2 1 

•  Abort  (Type  1 0 1 5)  -  page  2 1 


Client  Connection  Accepted  (Type  1000) 

This  message  is  sent  to  the  client  in  response  to  the  client’s  sending  message  type  2000 
followed  by  2001,  indicating  that  the  request  to  become  a  client  of  this  server  has  been 
granted,  and  the  server  is  now  ready  for  data  transactions.  Prior  to  sending  this  message, 
the  server  ensures  that  the  client  has  properly  identified  itself  (via  message  type  2000) 
and  has  enabled  at  least  one  interface  message  (via  message  type  2001)  within  10  seconds 
after  establishing  connection.  This  message  has  the  following  format: 


Table-5.  Client  Connection  Accepted  Message. 


Field  Name 

Field  Type 

Beg:Len 

Data  Type 

a.  Connection 

Accepted 

[1] 

0:var 

char 

b.  Date/Time 

UTC 

var:28 

DateTime 

[1]  This  message  data  field  has  a  variable  length,  formatted  as  a  NULL-terminated  ASCII 
character  string,  which  identifies  the  server’s  software  version.  The  field  length  shall  not  exceed 
200  bytes  including  the  NULL.  The  byte  order  is  not  applicable. 


Client  Connection  Refused  (Type  1001) 

This  message  indicates  that  the  request  to  become  a  client  of  this  server  has  been  refused 
due  to  the  fact  that  the  client  failed  to  follow  the  protocol  or  for  lack  of  connection 
resources  (too  many  clients  already  connected  to  the  server).  The  protocol  requires  the 
client  to  identify  itself  and  to  enable  at  least  one  interface  message  within  10  seconds 
after  establishing  connection.  This  message  has  the  following  format: 


Table-6.  Client  Connection  Refused  Message. 


Field  Name 

Field  Type 

Beg  Ten 

Data  Type 

a.  Connection  Refused 

[1] 

0:var 

char 

b.  Date/Time 

UTC 

var:28 

DateTime 

[1]  This  message  data  field  has  a  variable  length,  formatted  as  a  NULL-terminated  ASCII 
character  string,  which  indicates  the  reason  for  refusing  client  connection.  The  field  length  shall 
not  exceed  200  bytes  including  the  NULL.  The  byte  order  is  not  applicable. 


19 


Bearing-Range-Altitude-Refractivity  Profile  Data  (Type  1023} 

This  message  provides  modified  refractive  index  profile  data.  If  enabled,  the  RFC 
Module  sends  this  message  to  the  client  every  15  minutes  or  when  a  new  refractivity 
calculation  has  been  successfully  completed.  This  message  has  the  following  format: 


Table-7.  Bearing-Range-Altitude-Refractivity  Profile  Data  Message. 


Field  Name 

Field  Type 

Beg:Len 

Data  Type 

a.  Profile  Date/Time 

UTC 

0:28 

Date/Time 

b.  Profile  Latitude 

Latitude 

28:4 

float 

c.  Profile  Longitude 

Longitude 

32:4 

float 

d.  Profile  Quality 

Table  8 

36:4 

int 

e.  Profile  Type 

Table  9 

40:4 

int 

f.  Profile  Start  Bearing 

Degrees 

44:4 

float 

g.  Profile  Stop  Bearing 

Degrees 

48:4 

float 

h.  Evaporation  Duct  Height 

Alt  MSL 

52:4 

float 

i.  NRanges 

[1] 

56:4 

int 

j.  Range(l) 

NMI 

60:4 

float 

k.  NAIts(l) 

[2] 

64:4 

int 

1.  Altitude(l) 

Alt  MSL 

68:4 

float 

m.  Modified  Refractive  lndex(1) 

Refractivity 

72:4 

float 

m.  ... 

... 

n.  Altitude(NAIts(1 )) 

Alt  MSL 

68+8(NAIts(1)-1):4 

float 

o.  Modified  Refractive  lndex(NAIts(1)) 

Refractivity 

72+8(NAIts(1)-1):4 

float 

p.  ... 

q.  Range(NRanges) 

NMI 

68+[8(NAIts(1  ))]+[8+ 
8(NAIts(2)]+...]:4 

float 

r.  NAIts(NRanges) 

[2] 

Etc. 

int 

s.  Altitude(l) 

Alt  MSL 

float 

t.  Modified  Refractive  lndex(1) 

Refractivity 

float 

u.  ... 

v.  Altitude(NAIts(NRanges)) 

Alt  MSL 

float 

w.  Modified  Refractive  lndex(NAIts(NRanges)) 

Refractivity 

float 

[1]  NRanges  is  the  number  of  range-dependent  profiles  in  this  azimuth  sector 

[2]  NAlts  is  the  number  of  data  points  in  the  modified  refractive  index  profile  for  this  range 
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Table-8.  Profile  Quality  Codes. 


Bit 

Description 

0...7 

Data  Confidence  per  Table  3 

8.. .31 

Reserved 

Table-9.  Profile  Type. 


Value 

Description 

1 

Evaporative  Duct  Profile 

2 

Surface-Based  Duct  Profile 

3 

Profile  calculated  using  Standard  Atmosphere 

255 

Unknown  or  No  Data  Available  (Missing) 

Error  (Type  1014) 

The  server  sends  this  message  to  the  client  to  indicate  that  a  non-fatal  error  condition  has 
been  detected  by  server.  Always  enabled,  the  server  sends  this  message  to  the  client  upon 
server  non-fatal  error  detection.  This  message  has  the  following  format: 


Table-10.  Error  Message. 


Field  Name 

Field  Type 

Beg:Len 

Data  Type 

a.  Error  Message 

[1] 

0:var 

char 

b.  Date/Time 

UTC 

var:28 

DateTime 

[1]  This  message  data  field  has  a  variable  length,  formatted  as  a  NULL-terminated  ASCII 
character  string,  which  identifies  the  error  condition  detected  by  the  server.  The  field  length  shall 
not  exceed  200  bytes  including  the  NULL.  The  byte  order  is  not  applicable. 


Abort  (Type  1015) 

This  message  is  sent  to  the  client  to  indicate  that  a  fatal  error  condition  has  been  detected 
by  the  server,  which  will  result  in  the  server’s  terminating  processing.  This  message  is 
sent  to  client  prior  to  closing  the  socket  connection.  Always  enabled,  the  server  sends  this 
message  to  the  client  upon  fatal  error  detection  by  the  server.  This  message  has  the 
following  format: 


Table-1 1 .  Abort  Message. 


Field  Name 

Field  Type 

Beg:Len 

Data  Type 

a.  Abort  Message 

[1] 

0:var 

char 

b.  Date/Time 

UTC 

var:28 

DateTime 

[1]  This  message  data  field  has  a  variable  length,  formatted  as  a  NULL-terminated  ASCII 
character  string,  which  identifies  the  error  condition  detected  by  the  server.  The  field  length  shall 
not  exceed  200  including  the  NULL.  The  byte  order  is  not  applicable. 


21 


Client-to-Server  Messages 

The  client  may  send  the  following  messages  to  the  server: 

•  Request  to  Become  a  Client  (Type  2000) 

Request  to  Become  a  Client  (Type  2000) 

This  is  the  first  message  sent  by  the  client  after  establishing  a  socket  connection  with  the 
server.  This  message  identifies  the  requester.  If  the  server  cannot  honor  this  request,  it 
will  reply  with  the  Client  Connection  Refused  (Type  1001)  message.  If  the  server  accepts 
this  request,  it  will  reply  with  the  Client  Connection  Accepted  (Type  1000)  message.  This 
message  is  sent  upon  establishment  of  communications  with  the  server.  This  message  has 
the  following  format: 


Table-12.  Request  to  Become  a  Client  Message. 


Field  Name 

Field  Type 

Beg  Ten 

Data  Type 

a.  Request  to  become  a 
client 

[1] 

0:var 

b.  Date/Time 

UTC 

var:28 

DateTime 

[1]  This  message  data  field  has  a  variable  length,  formatted  as  a  NULL-terminated  ASCII 
character  string,  which  identifies  the  client  and  the  software  version  running  on  the  client.  The 
field  length  shall  not  exceed  200  bytes  including  the  NULL.  The  byte  order  is  not  applicable. 
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